The basic concepts of fast-packet networks are found in intelligent end-user systems, reliable digital transmission facilities, and high-speed communication systems. The growth in computer applications which require high speed communications, the proliferation of intelligent personal computers and work stations, and the growing availability of error-free high-speed transmission lines have combined to create a need for a new form of wide area network switching. This new switching technology requires high-speed, low delay, port sharing and band width sharing on a virtual circuit basis. TDM circuit switching provides the first two characteristics, and X.25 packet switching provides the last two. Fast-packet technology was developed as a new form of "packet mode" switching to provide all four characteristics, which together make fast-packet network an ideal solution for the bursty traffic sources found in LAN-WAN inter-networking.
Fast-packet technology offers users the ability to improve performance (response time) and reduce transmission costs dramatically for a number of important types of network applications. In order to be effective, fast-packet networks require that three conditions be met: (1) the end devices must be running an intelligent higher-layer protocol; (2) the transmission lines must be virtually error-free; and (3) the application must tolerate variable delay.
Other wide area network switching technologies, such as X.25 packet switching and TDM circuit switching, will remain important where line quality is not as good, when the network itself must guarantee error-free delivery or when the traffic (e.g., video or voice) is intolerant of delay.
A fast-packet network provides a "packet mode" service which uses statistical multiplexing and port sharing characteristics. However, unlike X.25, the fast-packet network completely eliminates all processing at Layer 3. Furthermore, it uses only a portion of the functions of Layer 2, the so-called "core aspects," which include checking for a valid error-free frame but not requesting retransmission if an error is found. Thus, protocol functions such as sequence number, window rotation, acknowledgements and supervisory packets are not performed within the fast-packet network. The result of stripping so many functions out of fast-packet network is that through-put (i.e., the number of frames that can be processed per second for a given cost of hardware) can be dramatically increased, since each packet requires much less processing. For the same reason, the delay through a fast-packet network is lower than that of X.25 although it remains higher than a TDM network which does no processing at all.
In order to be able to remove so many functions from the fast-packet network, the end devices must take the responsibility for assuring the error-free end-to-end transmission of data. The fact is that more and more of the end devices, particularly those attached to LANs, have the intelligence and processing power to perform that function.
Frame relay and cell relay are the two divisions of fast-packet technologies. Frame relay uses a framing structure which has variable lengths ranging from just a few characters to well over a thousand. This feature, which it shares with X.25, is very important in making frame relay operate well with LANs and other sources of synchronous data traffic, which require variable frame sizes. It also means that the delays encountered by the traffic (although always lower than X.25) will vary depending upon the sizes of the frames being sent. Some types of traffic are intolerant of delay, particularly delay which is variable. Voice is one example and video is another. For that reason, frame relay is not well suited to carrying such delay-sensitive traffic. On the other hand, it is very well matched to the requirements of bursty data sources such as LAN-to-LAN traffic.
When compared to X.25 packet, frame relay makes a small change to the frame structure by adding to the header at the beginning of the frame. The frame relay header contains the Data Link Connection Identifier (DLCI), which is the frame relay virtual circuit number corresponding with a particular destination. In the case of LAN-WAN inter-networking, the DLCI would denote the port to which the destination LAN is attached. The DLCI allows data coming into a frame relay network node to be sent across the network using a 3-step process:
1. Check the integrity of the frame using the Frame Check Sequence (FCS) and if it indicates an error, discard the frame.
2. Look at the DLCI in a table, and if the DLCI is not defined for this link, discard the frame.
3. Relay the frame toward its destination by sending it out the port or trunk specified in the table.
The two principal reasons frame relay data might be discarded are the detection of errors in the frame and the occurrence of congestion (the network is overloaded). The discard of frames does not interfere with the integrity of communications because of the intelligence in the end point devices such as PCs, work stations and hosts. These intelligent devices are operating with multi-level protocols which can detect and recover from loss of data in the network. The upper layer protocol in the end devices keeps track of the sequence numbers of the various frames sent and received. Acknowledgements are sent to inform the sending end which frame numbers have been successfully received. If a sequence number is missing, the receiving end will request a retransmittal. In this manner, the end devices assure that all of the frames eventually are received without errors.
FIG. 1 is a field diagram of the frame relay high-level data-link control (HDLC) format, comprising a flag area used for delimiting frames, followed by the DLCI area representing the addressing mechanism of frame relay. The DLCI consists of the six most significant bits of the second octet plus the four most significant bits of the third octet of the frame-relay frame. The DLCI bits of the second octet are followed by the Command/Response (C/R) indication bit. Additional bits, dependent upon the value of the extended address (EA) bit may be used to extend the DLCI beyond 10 bits to form a complete DLCI. The two-octet version of the DLCI shown in FIG. 1 covers 1024 addresses. In present implementations of frame relay, there are several restrictions placed on the assignment of DLCI values per ANSI specification. DLCI 0 is reserved for in channel call control signalling. DLCIs 1 through 15 and 1008 through 1022 are reserved for future use, and DLCI 1023 is reserved for Local Management Interface (LMI) communications. This leaves the 992 DLCIs from 16 through 1007 available for user data. DLCIs 16-991 are assigned to logical connections and DLCIs 992-1007 are used for Layer 2 management.
The DLCI area is followed by the Forward Explicit Congestion Notification (FECN) and Backward Explicit Congestion Notification (BECN) bits. The FECN bit indicates that congestion avoidance procedures should be started in the direction of the frame (Source.fwdarw.Network.fwdarw.End point). This bit may be used by the receiving end point to adjust the rate of the destination-controlled transmitter. The end point should slow down transmission of messages resulting in responses/acknowledgements.
The BECN bit indicates that congestion avoidance procedures should be started in the opposite direction of the frame (End point.fwdarw.Network.fwdarw.Source). This bit may be used by the receiving end point to adjust the rate of the source-controlled transmitters. The source should slow down all transmissions to the network.
The Discard Eligibility (DE) bit is used to indicate a frame's suitability for discard in network congestion situations. The indicated frames should be discarded in preference to other frames during congestion.
The information field of variable length carries user control data and information that are not interpreted by frame relay.
The two-octet Frame Check Sequence (FCS) field following the information field is used to verify that a frame is not corrupted during transmission. The FCS is the result of applying the Cyclic Redundancy Checking (CRC) polynomial to the frame from the first bit of the address field to the last bit of the information field. The FCS is calculated by the source device and recalculated by the destination device. If the two FCSs do not match, then the frame is discarded. The FCS is followed by a closing flag.
Cell relay is another division of fast-packet technologies. Like frame relay, cell relay requires intelligent end systems, reliable digital transmission facilities, and high-bandwidth capacities. The major difference between frame relay and cell relay is the units of information transferred. While frame relay transfers information in variable length "frames", cell relay transfers information in fixed length "cells".
The frame relay protocol is defined in standards listed in Table 1. Cell relay is defined in the ATM and 802.6 DQDB standards.
TABLE 1 ______________________________________ Frame relay and related standards Organization Standard Description ______________________________________ ANSI T1.606-1990 Integrated Services Digital Network (ISDN)-Frame Relay- ing Bearer Service-Architectural Framework and Service Descrip- tion for Frame Relaying Bearer Service ANSI T1S1/90-175R4 Addendum to T1.606 ANSI T1S1/88-2242 Frame Relay Bearer Service- Architectural Framework and Service Description ANSI T1S1/90-214 DSS1 - Core Aspects of Frame (T1.6ca) Protocol for Use with Frame Relay Bearer Service ANSI T1S1/90-213 DSS1 - Signalling Specification (T1.6fr) for Frame Relay Bearer Service CCITT I.122 Framework for Providing Additional Packet Mode Bearer Services CCITT I.431 Primary (1544.2048 Kbps) ISDN Interface CCITT Q.922 ISDN Data Link Layer Specifi- cation for Frame Mode Bearer Service CCITT Q.931 ISDN Network Protocol CCITT Q.933 ISDN Signaling Specification for Frame Mode Bearer Services ______________________________________
Currently, the frame relay and cell relay protocols are implemented in software and their throughput is restricted by processing power of systems providing software support of packet switching. Hence, there is a need for frame relay and cell relay to be implemented in hardware to eliminate processing bottlenecks of the software based fast-packet switching networks. Accordingly, it would be desirable to provide a packet management device able to perform packet address translation and packet routing to support frame or cell relay protocols in hardware.